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INTERNET PROTOCOL TELEPHONY to conditionally deposit a message in a called party's mes- 

VOICE/V1DEO MESSAGE DEPOSIT AND sage mailbox, in an Internet Protocol based network. 

RETRIEVAL It is another object of the present invention to provide a 

method of handling the SIP signaling requirements associ- 

BACKGROUND OF THE INVENTION 5 a ted with routing calls to an IMS to allow a calling party to 

1. Field of Invention unconditionally deposit a message in a called party's mes- 
Tlie present invention relates to Internet Protocol sage maQbox, in an Internet Protocol based network. 

telephony, and more particularly to a method for handling 11 K vel another object of the present invention to provide 

the signaling related to the storing and forwarding of voice a method of handling the SIP signaling requirements asso- 

and video messages in an Internet Protocol based network. ciated with routing calls to the IMS to allow a calling party 

2. Description of the Related Art t0 retrieve the deposited message in the called party's 

, _ . messaging mailbox, in an Internet Protocol based network. 

Internet Protocol (IP) telephony is the real time delivery - . , 

of voice, and other multimedia data, between two or more 11 * * U f°'her object of the present ,nvent,on to prov.de 

parties across a network using Internet protocols. Interne, is \«»thod °f handling the SIP signaling requirements asso- 

telephony began in the mid-1990's with PCto-PC Internet " ated / lth the « Ued P^X » hal a new "»»g? has 

telephony, which required both parties to have a personal ?een de P° s,ted f ' he c ' lled s messa § e ma,lbox > ln 40 

computer with specialized hardware and software, allowing Inte^le, Protoco1 based network - 

voice signals to be transmitted over the Internet. More To achieve the above objects, a method in accordance 

recently, IP telephony systems have been suggested which 20 wi,n tlle present invention is provided for signaling an IMS 

utilize the existing public switched telephone network on an IP based network to deposit a message, the method 

(PSTN) infrastructure integrated with IP networks, such as including the steps of sending a SIP INVITE request to the 

the Internet. IMS indicating a message deposit action; receiving a cor- 

Internet technology is session based, rather than connec- ^ponding SIP message from the IMS agreeing to partici- 

tion based. An Internet protocol, such as Session Initiation 25 in the message deposit action; and sending an SIP 

Protocols (SIP) is typically used to establish the session and acknowledge message to the IMS confirming receipt of the 

negotiate the capabilities for the session. Once the session is c ° rre sponding SIP message; and depositing the message in 

established, the actual media is transported across the IP a destlDallon mailbox. 

network using a different protocol, such as Real-time Trans- Mso provided is a method of signaling an IMS on an IP 
port Protocol (RTP). IP telephony use has advanced rapidly 30 based network to retrieve a deposited message, the method 
since its introduction. including the steps of sending a SIP INVITE request to the 
IP telephony has advantages over the PSTN, providing a 1MS Skating a message retrieval action; receiving a 
cost savings for both users and carriers while allowing the corresponding SIP message from the IMS agreeing to par- 
transport of a variety of media types, such as voice and ^pate in the message retrieval action; sending an SIP 
video, as opposed to just voice as in the case of the PSTO. 35 ackoow ^g e ^sage to the IMS confirming receipt of the 
While IP telephony may someday replace the PSTN, it corresponding SIP message; and retrieving the deposited 
suffers some disadvantages in that it currently lacks many of ^ssage from a mailbox corresponding to known account 
the features already developed for the PSTN. One such information. 

feature is call message deposit and retrieval. ^ BRIEF DESCRIPTION OF THE DRAWINGS 

The SIP protocol is currently a leading protocol for 
establishing IP telephony sessions. However, currently no ^ above and other ob J ects ' feaUires ' and advantages of 
definitions have been established in the SIP protocol to the P resent m ^ ni ^ n ^ become more apparent in light of 
handle the call forwarding logic and signaling requirements the followm g detaiIed description of an exemplary embodi- 
necessary for proper interfacing with messaging systems for 45 ment thereof taken in conjunction with the attached draw- 
message deposit and retrieval. The conditional forwarding m & s m wmcn: 

of calls for deposit in a messaging system is generally done 1 is a block diagram illustrating a system supporting 

when a called party is either busy or fails to answer a call. tne method of the present invention; and 

A called party may also wish to have a caller unconditionally FIG. 2 is a flow chart illustrating a method of depositing 

deposit a message in a messaging system. In either case, the 5Q a message in accordance with an embodiment of the present 

messaging system interface must provide signaling capa- invention 

bilities to store the message, whether conditionally or FIG. 3 is a flow chart illustrating a method of retrieving 

unconditionally, and also for a called party to later retrieve a message in accordance with an embodiment of the present 

the deposited message. The signaling capabilities must also invention, 
include information about the calling party depositing the „ 

message. The identity of the called party must also be DETAILED DESCRIPTION OF THE 

verified when he or she retrieves the deposited message. PREFERRED EMBODIMENT 

Therefore, a need exists for a method of handling the Turning now to the drawings, in which like reference 

signaling required for IP telephony voice and video message numerals identify similar or identical elements throughout 

deposit and retrieval in an IP based network using the SIP 60 the several views, FIG. 1 is a block diagram illustrating a 

protocol, thereby allowing integration of the IP network with system providing telephony services between and among 

an Integrated Messaging System (IMS). subscribers using traditional telephones 13 and Internet 



SUMMARY OF THE INVENTION 



telephones 15. Signaling and media for calls are transported 
over the Internet 17. 



It is therefore an object of the present invention to provide 65 Traditional telephones 13 are connected to the Internet 17 
a method of handling the SIP signaling requirements asso- through traditional telephone switching equipment, such as 
ciated with routing calls to an IMS to allow a calling party PBX's and IP telephony gateways 21. IP telephony gateways 
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21 each include a signaling gateway (not shown) and a instance, a 200 OK message, the caller confirms that it has 

media gateway (not shown). The signaling gateway provides received that response by sending an ACK request. If the 

bi-directional transportation between PSTN telephony sig- caller no longer wants to participate in the call, it sends a 

naling and IP telephony signaling messages, such as SIP. IP BYE request instead of an ACK. The INVITE request 

phones 15 may be connected directly to the Internet through 5 typically contains a session description that provides the 

a local area network or by a modem connection through an called party with enough information to join the session. The 

Internet service provider. session description enumerates the media types and formats 

Generally, call signaling and media are transported across tnat the calJ er is willing to use and where it wishes the media 

the Internet 17 between an originating IP telephony gateway data 10 De sent - If the called party wishes to accept the call, 

21a and a destination IP telephony gateway 21b. Typically, *o it responds to the invitation by returning a similar descrip- 

routing information is supported by a proxy server, such as ti° n listing the media it wishes to use. 

a network server (NS) 23. The NS 23 also provides call The SIP INVITE request of the current invention includes 

control and call forwarding control. That is, the NS 23 an additional header added by the NS 23. The added header 

includes an intermediary application program that acts as will use the SIP Require header protocol extension mecha- 

both a server and a client for the purposes of making 15 nism. The Require header is used to tell the IMS 25 about the 

requests on behalf of other clients or, referred to generally as options that must be supported. The proposed format for this 

calling parties hereinafter. In the SIP protocol an INVITE header includes a suitable tag, such as: 
request is sent from the originating IP telephony gateway 

21a to the address of the called party at the NS 23. IP call Required; org.ietf.messagiiig 

setup signaling messages are transported back and forth 20 

between the IP telephony gateways 21 and the NS 23 until and the followiD S parameters: 

the call is setup using the SIP protocol, as is commonly . u . „ /UJ . „. . „ rt 

, . , messaging-param= action- ( deposit | retrieval ') 
known in the art. 

The system also includes a location manager 31, which deposit-type- M dtype-"("cfu"| u cfb*f cfna") 

provides gateway selection and mobility management ser- 25 , . 

vices to the NS 23. The location manager 31 functions as an where * e actlon P aramete ' identifies whether a deposit or 

SIP redirect server. A redirect server is a server that accepts relneval °P eratl0a 15 being performed and the dtype param- 

an SIP request, maps the address into zero or more new eter Ermines the call forwarding condition. The dtype 

addresses and returns these addresses to the sender, for P a rameter which is required only for deposit actions, 

instance the NS 23. Unlike an SIP proxy server such as the 30 deludes values: cfu for call forwarding unconditional; cfb, 

NS 23, a redirect server does not initiate its own SIP requests for cal1 forwardin g husy; and cfha, for call forwarding no 

or accept calls. Thus, if the NS 23 cannot send a session answer. ^ ^ 

initiation request to the IP telephony gateway 21, the NS 23 ^ NS 23 a ^ the Re 1 uire header and dialed 

sends a session initiation request to the called party at the parameters to the SIP INVITE request forwarded to the IMS 

location manager 31. The location manager 31 either con- 35 25 „ b y the m J y ^ NS 23 must first establish whether a 

suits its own database or accesses the legacy service control called party, being an IMS account user, has selected to have 

entity 29 to obtain a new address for the called party. The aU calk unconditionally forwarded to his message mailbox 

location manager 31 then returns the new address to the NS in the IMS 2S ' 11115 informat i°n acquired from the called 

23 party by the NS 23 via a call made by the called party to the 

¥ , 4l _ „ , . , , . , 40 NS 23 when the called party activates the unconditional call 

In cases where the called party can not be reached i.e. the forwardi feature on , he ^ed party > s telephone, or other 

phone is busy or not answered the call is forwarded to an communicatillg device . ^ NS 33 determ ines whether a 

Integrated Messaging System (IMS) 25. In order to properly A „ • r. u c . - « 

c a a '* j * ■ \u ■ *l « called party is busy as a result of receiving a busy response, 

forward, deposit and retrieve the messages in the IMS 25, , . uaZst* u »■ * .if iKnrrrv 

*u KTcii . • . ™?o->c (U PI n such as "486 Busy Here , in response to the INVITE request 

the NS 23 must communicate with the IMS 25 using the SIP Me f tU KTC f t u « a * a • * 1 u \. 

. 0 tl _!/.■,■ .... . 45 from the NS 23 to the called party during initial call setup. 

protocol. Currently there are no definitions established for t*. mc , _ < c „ , * „ • . 

*u Pin / i. L ,, ... , ,. r j* lne NS 23 determines whether a called party is not answer- 

using the SIP protocol to handle conditional call forwarding m M a ^ of fcceivin , , ^ se tQ 

log.c ana me Signaling requirements necessary tor proper ^ 1Nvrr£ &Qm ^ m ^ 

to the called party 

interfacing w.th messaging systems. The present invention d ■ MU caU 

establishes the SIP signahng requ.rements for interfacing 5Q ^ ^ flQW fof , jp „ between c 

with an IMS 25. , „ . * OI „ \ . . „ . 6 

party and a called party using the SIP protocol is well known 

The NS 23 sends one or more SIP requests to the IMS 25 m tne art and not detailed herein to avoid unnecessarily 

and receives one or more responses from the IMS 25. A obscuring the invention. The present invention therefore 

request (and its retransmissions) together with the responses focuses on the method of communications required between 

triggered by that request make up a SIP transaction. All 55 me NS 23 and IMS 25, and more particularly the addition of 

responses to a request contain the same values in the the Require header and its associated parameters. 

Call-ID, CSeq, To, and From, as shown in the examples Referring to FIG. 2, a method of depositing a message 

below. This allows responses to be matched with requests. mX o me IMS 2 5 begins with a call setup and routing to the 

The functions served by these parameters are commonly ca n e d party as described above and as represented in step 

known in the art. 60 2 00. In step 205 the NS 23 determines if the called party has 

A successful SIP invitation consists of two requests, previously activated the unconditional call forwarding fea- 

INVlTb followed by an ACK request. The ACK request ture. If the unconditional call forwarding feature has been 

following an INVITE is not part of the transaction since it activated by the called party, the NS 23 sends an SIP 

may traverse a different set of hosts, the INVITE request INVITE request to the IMS 25 which includes the additional 

asks the called party to join a particular conference or 65 Require header with the parameters action«deposit and 

establish a two-party conversation. After the called party has dtype«cfu in step 206 to indicate an unconditional call 

agreed to participate in the call by responding with, for forwarding message deposit. However, if the unconditional 
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call forwarding feature has not been activated by the called 
party, the NS 23 determines if a busy response, such as 486 
Busy Here, is received in response to the INVITE request 
from the NS 23 to the called party during initial call setup 
in step 210. If a busy response is received, the NS 23 sends 
an SIP INVITE request to the IMS 25 which includes the 
additional Require header with the parameters action= 
deposit and dtype=cfb in step 211 to indicate a conditional 
busy call forwarding message deposit. However, if the busy 
response is not received by the NS 23, the NS 23 determines 
if the called party is not answering in step 215, or more 
particularly, whether a request time-out has been received by 
the NS 23 in response to the INVITE request from the NS 
23 to the called party during initial call setup. If a request 
time-out is received, the NS 23 sends an SIP INVITE request 
to the IMS 25 which includes the additional Require header 
with the parameters action=deposit and dtype-cfna in step 
216 to indicate a conditional no answer call forwarding 
message deposit. However, if the request time-out is not 
received by the NS 23, the NS 23 determines if the NS 23 
receives a connect signal in step 245 and completes the call 
setup to the called party in step 250. 

In steps 206, 211, or 216, a typical SIP INVITE request 
call flow sent from the NS 23 to the IMS 25 including the 
additional SIP Require header is shown below: 



-continued 



15 



20 



25 



Content-Type: application/sdp 

Content-Length:... 

v-0 

0- UserB 2890844527 2890844527 IN IP4 cUent.therc.com 

1- O 0 
t-0 0 

oIN IP4 110.111.112.113 
m-audio 3456 RTP/AVP 0 
a=rtpmap:0 PCMU/8000 



The NS 23 then confirms that it has received a final 
response to the SIP INVITE request in step 230 by sending 
an ACK message to the IMS 25, typically as shown below: 



ACK sip:IMS-mailbox-id@ims. wcom.com SIP/2.0 

VIA: SIP/2.0/UDP calling-host.com 

VIA: SIP/2.0/UDP ns.wcom.com 

Route: <stp:calling-user@calling-host.com> 

From: Calling User <sip:calling-user@calling-host.com> 

To: Called User <sip:called-user@sip.wcom.com> 

Callid: 123456@calling-host.com 

CSeq: 1 ACK 

Content- Length: 0 



INVITE sip: I MS- mailbox-id@ims.wcom.com SIP/2.0 

VIA: SIP/2.0/UDP calling-host.com 

VIA: SIP/2.0/UDP ns.wcom.com 

Record-Route: <sip:ns. wcom.com > 

From: Calling User <sip:calting-user@calling-host.com> 

To: Called User <sip:called-user@sip.wcom.com> 

Callid: 123456@calling-host.com 

CSeq: 1 INVITE 

Contact: <sip:calling-user@calling-host.com> 
Required: org.ietf.messaging 
action=deposit 
dtype=cfb 

Content-Type: application/sdp 

Content-Length:... 

v-0 

o-UserA 2890844526 2890844526 IN IP4 client.here.com 
t=0 0 
t-0 0 

c=IN IP4 100.101.102.103 
m=audio 49170 RTP/AVP 0 
a-rtpmap:0 PCMU/8000 



In the above example the dtype parameter selected con- 
tains the value cfb, indicating a conditional busy call for- 
warding deposit operation, as in step 210. This parameter 
would differ for the SIP INVITE request of steps 205 and 
245 and would instead be cfu and cfna, respectively. 

In any case, the IMS 25 responds to the SIP INVITE 
request by sending a 200 OK message to the NS 23 in step 
225, indicating that the request was successful and the IMS 
25 has agreed to participate in the call with the NS 23. A 
typical response is shown below: 



The message, being of video or voice content, is then 
deposited into the called party's mailbox address, the called 
party being an IMS account user, by the IMS 25 in step 235. 
30 Communication is then terminated via normal SIP BYE 
processing in step 240. 

A method of retrieving a deposited message in accordance 
with the present invention is illustrated in FIG. 3. Referring 
to FIG. 3, an IMS account user is notified of a message 
35 having been deposited into the user's mailbox via a call 
placed by the IMS 25 activating a message alert feature on 
the user's phone, or other communicating device, in step 
300. The user's subsequent call to retrieve the deposited 
message is setup and routed to the IMS 25 by the NS 23 in 
40 step 300. The content of SIP INVITE request will vary 
according to three possible scenarios, as determined in steps 
305 and 340. However, in any case the SIP INVITE request 
will include the additional Require header with only the 
action=retrieval parameter. 
45 In step 305, if the IMS account user's account information 
has been authenticated by the NS 23, the call flow between 
the NS 23 and IMS 25 will, for example, be as follows, 
beginning with step 310 in which the NS 23 sends the SIP 
INVITE request. 



SIP/2.0 200 OK 

VTA: SIP/2.0/UDP calling-hosLcom 

VIA: SIP/2.0/UDP ns.wcom.com 

Record-Route: <sip:ns.wcom.com> 

From: Calling User <sip:calling-user@calling-host.com> 

To: Called User <sip:callcd-user@sip.wcom.com> 

Callid: l23456@ealling-host.com 

CSeq: 1 INVITE 

Contact: <sip:tMS-mailbox-td @ims.wcom.host.com> 



55 



60 



INVITE sip :IMS-accoun t-id@ims.wcom.com SIP/10 
VIA: SIP/2.0/UDP calling-host.com 
VIA: SIP/2.0/UDP ns.wcom.com 
Record- Route: <sip; ns.wcom.com > 
From: Calling User <sip:calling-usc r@calling-host.com> 
■ To: voicemail <sip:voicemail@sip.wcom.com> 
Callid: 123456@calling-hosLcom 
CSeq: 1 INVITE 

Contact: <sip:cal ling-use r@calling-host.com> 

Required: org.ietf.messaging 

action=retrieval 

Content-Type: application/sdp 

Content-Length:... 

v-0 

o-UserA 2890844526 2890844526 IN IP4 clienthere.com 
t-0 0 
t-0 0 

c-IN IP4 100.101.102.103 
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-continued 

m-audio 49170 KTP/AVP 0 
a-rtpmaprO PCMU/SOOO 



The IMS 25 responds to the SIP INVITE request by 
sending a 200 OK message to the NS 23 in step 315, 
indicating that the request was successful and the IMS 25 
has agreed to participate in the call with the NS 23. A typical 
response is shown below: 



SIP/2.0 200 OK 

VIA: SIP/2.0/UDP ca 1 ting- hosL com 

VIA: SIP/2.0/UDP ns.wcom.com 

Record- Route: <sip:ns. wcom.com> 

From: Calling User <sip:cal licg-user@calling-host.com> 

To: voicemail <sip^oicemail@sip.wcom.com> 

Callid: 1 2345 6@calling-hos Leo m 

CSeq: 1 INVITE 

Contact: <sip: IMS- mailbox-id @ims.wcom.host.com> 

Content-Type: applies tion/sdp 

Content-Length:... 

v-0 

o=UserB 2890844527 2890844527 IN IP4 client.there.com 
t=0 0 
t-0 0 

c-IN IP4 110.311.112.113 
m-audio 3456 RTP/AVP 0 
a=rtpmap:0 PCMU/8000 



The NS 23 then confirms that it has received a final 
response to the SIP INVITE request in step 320 by sending 
an ACK message to the IMS 25, typically as shown below: 



ACK sip:IMS-mailbox-id@ims.wcom.com SIP/2.0 

VIA: SIP/2.0/UDP calling-host.com 

VIA: SIP/2.0/UDP ns.wcom.com 

Route : <sip :call ing-us er@cal 1 ing-host. com > 

From: Calling User <sip:calling-user@cal]ing-hosLcom> 

To: voicemaU <sip:voicemail @sip.wcom.com> 

Callid: 123456@calling-host.com 

CSeq: 1 ACK 

Content-Length: 0 



-continued 



Callid: 123456@calling-host.com 
CSeq: 1 INVITE 
5 Contact: <sip:cal ling-use recalling- host.com > 

Required: org.ietf. messaging 
action- retrieval 
Content-Type: application/sdp 
Content-Length:... 
v-0 

30 o=UserA 2890844526 2890844526 IN IP4 clienthere.com 

t-0 0 
t-0 0 

c-IN IP4 100.101.102.103 
m-audio 49170 RTP/AVP 0 
a=rtpmap:0 PCMU/8000 



The IMS 25 responds to the SIP INVITE request by 
sending a 200 OK message to the NS 23 in step 350, 
indicating that the request was successful and the IMS 25 
has agreed to participate in the call with the NS 23. Atypical 
20 response is shown below: 



SIP/2.0 200 OK 

VIA: SIP/2.0/UDP calling-host.com 
25 VIA: SIP/2.0/UDP ns.wcom.com 

Record-Route: <sip:ns,wcom.com> 

From: Calling User <sip:calling-user@calling-host.com> 

To: voicemail <sip:voicemail@sip.wcom.com> 

Callid: 123456@calling-host.com 

CSeq: 1 INVITE 
30 Contact: <sip:IMS- mailbox- id @ims.wcom host.com> 

Content-Type application/sdp 

Content-Length:... 

v=0 

o-UserB 2890844527 2890844527 IN IP4 clicnt.there.com 
t-0 0 

35 t=0 0 

c=IN IP4 110.131.112.113 
m-audio 3456 RTP/AVP 0 
a-rtpmap:0 PCMU/8000 



40 The NS 23 then confirms that it has received a final 
response to the SIP INVITE request in step 355 by sending 
an ACK message to the IMS 25, typically as shown below: 



In the above scenario, no prompting is required since the 
IMS account user's information is authenticated and, in step 
325, the IMS 25 uses the account information indicated in 
the INVITE request Uniform Resource Locator (URL). 
Thereafter, the calling user is granted access to the mailbox 
in step 410 and the message is retrieved in step 415, which 
is followed by normal SIP BYE processing at step 420 to end 
the call. 

On the other hand, if the IMS account user cannot be 
authenticated in step 305, and the user is accessing the IMS 
25 from a device that has a default IMS account associated 
with it in step 340, the procedure instead continues to step 
345, providing an SIP INVITE request from the NS 23 to the 
IMS 25 as follows, for example: 



INVITE sip :IMS-accound-id:????@ims. wcom.com SIP/2.0 

VIA: SIP/2.0/UDP calling-hosLcom 

VIA: SIP/2.0/UDP ns.wcom.com 

Record- Route: <sip:ns.wcom.com> 

From: Calling User <sip:callLng-user@calling-host.com> 

To: voicemail <sip:voicemail@sip.wcom.com> 



45 ACK sip: IMS- mailbox- id@ims.wcom.com SIP/2.0 

VIA: SIP/2.0/UDP cal ling-host.com 
VIA: SIP/2.0/UDP ns.wcom.com 
Route : <sip : cal Iing-user@call ing- host.com > 
From: Calling User <sip:calling-user@calling-host.com> 
To: voicemail <sip:voicemail @sip. wcom.com> 

50 Callid: 123456@calling-host.com 

CSeq: 1 ACK 
Content-Length: 0 



The SIP INVITE request above contains the account 
55 information, with no password authentication. At this point, 
the IMS 25 prompts the calling IMS account user for a 
password to verify the account contained in the INVITE 
request URL in step 360. If the account is verified, the 
procedure continues to steps 410-420 as described above. If, 
60 however, the password entered is incorrect, or the user 
indicates he or she is calling from a device with a default 
account assigned to it corresponding to another user's 
account, then the IMS 25 prompts the user for a user name 
and password in step 395 and continues to step 400 as 
65 described below. 

However, if in step 340, the IMS account user is accessing 
the IMS 25 from a gateway or other device that does not 
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have a default IMS account assigned to it, the NS 23 sends 
an account unknown SIP INVITE request to the IMS 25 in 
step 380 as shown below: 



INVITE sip : U NKNO W N@i ms.wcom.com SIP/2.0 

VIA: SIP/2.0/UDP calling-hostxom 

VIA: SIP/2.0/UDP ns.wcom.com 

Record-Route: <sip:ns.wcom.com> 

From: Calling User <sip:calling-user@calling-host.com> 

To: voicemail <sip :voiccmail@sip.wcom.com> 

Callid: 123456@calling-hosLcom 

CSeq: 1 INVITE 

Contact: <sip:cal ling- user@calling-host.com> 

Required: org. ietf. messaging 

actio n=retrieval 

Content-Type: application/sdp 

Content-Length:... 

v»0 

o-UserA 2890844526 2890844526 IN IP4 ctient.here.com 
t-0 0 
t-0 0 

c-IN IP4 100.101.102.103 
m-audio 49170 RTP/AVP 0 
a-rtpmap:0 PCMU/8000 



The IMS 25 responds to the SIP INVITE request by 
sending a 200 OK message to the NS 23 in step 385, 
indicating that the request was successful and the IMS 25 
has agreed to participate in the call with the NS 23. Atypical 
response is shown below: 



SIP/2.0 200 OK 

VIA: SIP/2.0/UDP caUing-host.com 

VIA: SIP/2.0/UDP ns.wcom.com 

Record- Route: <sip:ns.wcom.com> 

From: Calling User <sip:calling-user@calling-host.com> 

To: voicemail <sip:voicemail@sip.wcom.com> 

Callid: 123456@caliing-host.coin 

CSeq: 1 INVITE 

Contact: <sip : IMS- mailbox-id @ims.wcom.host.com> 

Content-Type: application/sdp 

Content-Length:... 

v-0 

o-UserB 2890844527 2890844527 IN IP4 client.there.com 
t-0 0 
t=0 0 

c-IN IP4 110.111.112.113 
m-audio 3456 RTP/AVP 0 
a-rtpmap:0 PCMU/8000 



The NS 23 then confirms that it has received a final 
response to the SIP INVITE request in step 390 by sending 
an ACK message to the IMS 25, typically as shown below: 



ACK sip:IMS-mailbox-id@ims.wcom.com SIP/2.0 

VIA: SIP/2.0/UDP calling-hosLcom 

VIA: SIP/2.0/UDP ns.wcom.com 

Route: <5ip.caUmg-user@callmg-host.com> 

From: Calling User <sip:calling-user@calling-host.com> 

To: voicemail <sip voicemail @sip.wcom.com> 

Callid: 123456@ca11ing-hosLcom 

CSeq: 1 ACK 

Content-Length: 0 



In this case, the SIP INVITE request contains no account 
or authentication information, but only the identifier 
UNKNOWN in the INVITE request URL. Accordingly, in 
step 395, a calling party is prompted for a user name and 
password. If the account is verified in step 400, the proce- 
dure continues to steps 410-420 as described above. 
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However, if the user name and password is entered 
incorrectly, the user is allowed a predetermined number of 
re-entry attempts in step 405 before the operation is aborted, 
ending the call in step 406. 

5 While the present invention has been described in detail 
with reference to the preferred embodiments, they represent 
mere exemplary applications. Thus, it is to be clearly under- 
stood that many variations can be made by anyone of 
ordinary skill in the art while staying within the scope and 

10 spirit of the present invention as defined by the appended 
claims. 

What is claimed is: 

1. A method of signaling an Integrated Messaging System 
(IMS) on an Internet Protocol (IP) based network to deposit 

15 a message, comprising the steps of: 

sending a Session Initiation Protocol (SIP) INVITE 
request to the IMS indicating a message deposit action; 
receiving a corresponding SIP message from the IMS 
agreeing to participate in the message deposit action; 
20 and 

sending an SIP acknowledge message to the IMS con- 
firming receipt of the corresponding SIP message. 

2. The method recited in claim 1, further comprising the 
25 step of depositing the message in a destination mailbox. 

3. The method recited in claim 2, wherein the deposited 
message includes voice data. 

4. The method recited in claim 2, wherein the deposited 
message includes video data. 

3Q 5. The method recited in claim 1, wherein the SIP INVITE 
request includes a Require header following the SIP Require 
header protocol extension mechanism. 

6. The method recited in claim 5, wherein the Require 
header includes at least a first and second parameter, wherein 

35 the first parameter indicates the message deposit action to 
the IMS and the second parameter is a call forwarding 
parameter. 

7. The method recited in claim 6, wherein the call 
forwarding parameter identifies whether the message was 

4Q deposited unconditionally or conditionally based on a busy 
signal condition of a called party or a no answer condition 
of the called party. 

8. A method of signaling an Integrated Messaging System 
(IMS) on an Internet Protocol (IP) based network to retrieve 

45 a deposited message, comprising the steps of: 

sending a Session Initiation Protocol (SIP) INVITE 
request to the IMS indicating a message retrieval 
action; 

receiving a corresponding SIP message from the IMS 
50 agreeing to participate in the message retrieval action; 
and 

sending an SIP acknowledge message to the IMS con- 
firming receipt of the corresponding SIP message. 

9. The method recited in claim 8, wherein the IMS sends 
55 and receives messages from a secure Network Server (NS). 

10. The method recited in claim 8, further comprising the 
step of retrieving the deposited message from a mailbox 
corresponding to known account information. 

11. The method recited in claim 10, wherein the known 
60 account information includes an account identification 

which has been authenticated. 

12. The method recited in claim 10, wherein the known 
account information includes an account identification 
which is not authenticated, and wherein the method includes 

65 the further step of prompting a user for a password. 

13. The method recited in claim 10, wherein the known 
account information includes no account identification, and 
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wherein the method includes the further step of prompting a 
user for a user name and password. 

14. The method recited in claim 12, further comprising the 
step of asking the user for a user name and a new password 
when an incorrect password is entered for the prompted 5 
password. 

15. The method recited in claim 10, wherein the retrieved 
message includes voice data. 

16. The method recited in claim 10, wherein the retrieved 
message includes video. io 

17. The method recited in claim 8, wherein the SIP 
INVITE request includes a Require header following the SIP 
Require header protocol extension mechanism. 

18. The method recited in claim 17, wherein the Require 
header includes at least a first parameter, wherein the first 15 
parameter indicates the message retrieval action to the IMS. 

19. The method recited in claim 8, wherein an IMS 
account user is notified when the deposited message is ready 
for retrieval. 

20. A method of signaling an Integrated Messaging Sys- 20 
tem (IMS) on an Internet Protocol (IP) based network to 
deposit a message and retrieve the deposited message, 
comprising the steps of: 
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sending a Session Initiation Protocol (SIP) INVITE 
request to the IMS indicating a message deposit action; 

receiving a corresponding SIP message from the IMS 
agreeing to participate in the message deposit action; 

sending an SIP acknowledge message to the IMS con- 
firming receipt of the corresponding SIP message; 

depositing the message in a destination mailbox; 

sending a Session Initiation Protocol (SIP) INVITE 
request to the IMS indicating a message retrieval 
action; 

receiving a corresponding SIP message from the IMS 
agreeing to participate in the message retrieval action; 

sending an SIP acknowledge message to the IMS con- 
firming receipt of the corresponding SIP message; and 

retrieving the deposited message from the destination 
mailbox, wherein the destination mailbox corresponds 
to known account information. 

***** 
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